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Abstract 

Fran (Functional Reactive Animation) is a collection of data 
types and functions for composing richly interactive, multi- 
media animations. The key ideas in Fran are its notions of 
behaviors and events. Behaviors are time-varying, reactive 
values, while events are sets of arbitrarily complex condi- 
tions, carrying possibly rich information. Most traditional 
values can be treated as behaviors, and when images are 
thus treated, they become animations. Although these no- 
tions are captured as data types rather than a programming 
language, we provide them with a denotational semantics, 
including a proper treatment of real time, to guide reason- 
ing and implementation. A method to effectively and ef- 
ficiently perform event detection using interval analysis is 
also described, which relies on the partial information struc- 
ture on the domain of event times. Fran has been imple- 
mented in Hugs, yielding surprisingly good performance for 
an interpreter-based system. Several examples are given, in- 
cluding the ability to describe physical phenomena involving 
gravity, springs, velocity, acceleration, etc. using ordinary 
differential equations. 

1 Introduction 

The construction of richly interactive multimedia anima- 
tions (involving audio, pictures, video, 2D and 3D graph- 
ics) has long been a complex and tedious job. Much of 
the difficulty, we believe, stems from the lack of sufficiently 
high-level abstractions, and in particular from the failure 
to clearly distinguish between modeling and presentation, or 
in other words, between what an animation is and how it 
should be presented. Consequently, the resulting programs 
must explicitly manage common implementation chores that 
have nothing to do with the content of an animation, but 
rather its presentation through low-level display libraries 
miming on a sequential digital computer. These implemen- 
tation chores include: 

• stepping forward discretely in time for simulation and 
for frame generation, even though animation is con- 
ceptually continuous; 
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• capturing and handling sequences of motion input events, 
even though motion input is conceptually continuous; 

• time slicing to update each time- varying animation pa- 
rameter, even though these parameters conceptually 
vary in parallel; and 

By allowing programmers to express the "what" of an 
interactive animation, one can hope to then automate the 
"how" of its presentation. With this point of view, it should 
not be surprising that a set of richly expressive recursive 
data types, combined with a declarative programming lan- 
guage, serves comfortably for modeling animations, in con- 
trast with the common practice of using imperative lan- 
guages to program in the conventional hybrid modeling/- 
presentation style. Moreover, we have found that non-strict 
semantics, higher-order functions, strong polymorphic typ- 
ing, and systematic overloading are valuable language prop- 
erties for supporting modeled animations. For these reasons, 
Fran provides these data types in the programming language 
Haskell [9]. 

Advantages of Modeling over Presentation 

The benefits of a modeling approach to animation are similar 
to those in favor of a functional (or other declarative) pro- 
gramming paradigm, and include clarity, ease of construc- 
tion, composability, and clean semantics. But in addition 
there are application-specific advantages that are in some 
ways more compelling, painting the picture from a software 
engineering and end-user perspective. These advantages in- 
clude the following: 

• Authoring. Content creation systems naturally con- 
struct models, because the end users of such systems 
think in terms of models and typically have neither the 
expertise nor interest in programming presentation de- 
tails. 

• Optimizability. Model-based systems contain a presen- 
tation sub-system able to render any model that can be 
constructed within the system. Because higher-level 
information is available to the presentation sub-system 
than with presentation programs, there are many more 
opportunities for optimization. 

• Regulation. The presentation sub-system can also more 
easily determine level-of-detail management, as well 
as sampling rates required for interactive animations, 
based on scene complexity, machine speed and load, 
etc. 
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• Mobility and safety. The platform independence of 
the modeling approach facilitates the construction of 
mobile applications that are provably safe in World 
Wide Web applications. 

The Essence of Modeling Our goal in this paper 
is to convey the essence of a modeling approach to reac- 
tive animations as captured in Fran, as summarized in the 
following four concepts: 

1. Temporal modeling. Values, called behaviors, that 
vary over continuous time are the chief values of inter- 
est. Behaviors are hrst-class values, and are built up 
compositionally; concurrency (parallel composition) is 
expressed naturally and implicitly. As an example, the 
following expression evaluates to an animation (i.e., an 
image behavior) containing a circle over a square. At 
time t, the circle has size sin t, and the square has size 
cost. 

bigger (sin time) circle 'over' 
bigger (cos time) square 

2. Event modeling. Like behaviors, events are hrst- 
class values. Events may refer to happenings in the 
real world (e.g. mouse button presses), but also to 
predicates based on animation parameters (e.g. prox- 
imity or collision). Moreover, such events may be com- 
bined with others, to an arbitrary degree of complexity, 
thus factoring complex animation logic into semanti- 
cally rich, modular building blocks. For example, the 
event describing the hrst left-button press after time 
tO is simply lbp tO; one describing time squared being 
equal to 5 is just: 

predicate (time "2 ==5) tO 

and their logical disjunction is just: 

lbp tO . I . predicate (time~2 == 5) tO 

3. Declarative reactivity. Many behaviors are natu- 
rally expressed in terms of reactions to events. But 
even these "reactive behaviors" have declarative se- 
mantics in terms of temporal composition, rather than 
an imperative semantics in terms of the state changes 
often employed in event-based formalisms. For ex- 
ample, a color- valued behavior that changes cyclically 
from red to green with each button press can be de- 
scribed by the following simple recurrence: 

colorCycle tO = 

red 'untilB' lbp tO *=> \tl -> 
green 'untilB' lbp tl *=> \t2 -> 
colorCycle t2 

(In Haskell, identifiers are made into inhx operators 
by backquotes, as in b 'untilB' e. Also, inhx opera- 
tors can be made into identifiers by enclosing them in 
parentheses, as in (+) x y. Lambda abstractions are 
written as "\ vars -> exp , \) 



4. Polymorphic media. The variety of time-varying 
media (images, video, sound, 3D geometry) and pa- 
rameters of those types (spatial transformations, col- 
ors, points, vectors, numbers) have their own type- 
specihc operations (e.g. image rotation, sound mixing, 
and numerical addition), but ht into a common frame- 
work of behaviors and reactivity. For instance, the 
"untilB" operation used above is polymorphic, apply- 
ing to all types of time-varying values. 

Our Contributions We have captured the four fea- 
tures above as a collection of recursive data types, functions, 
and primitive graphics routines in a system that we call 
Fran, for Functional Reactive Animation. Although these 
data types and functions do not form a programming lan- 
guage in the usual sense, we provide them with a formal 
denotational semantics, including a proper treatment of real 
time, to allow precise, implementation-independent reason- 
ing. This semantics includes a CPO of real time, whose ap- 
proximate elements allow us to reason about events before 
they occur. As would be true of a new programming lan- 
guage, the denotational semantics has been extremely useful 
in designing Fran. All of our design decisions begin with an 
understanding of the formal semantics, followed by reflect- 
ing the semantics in the implementation. (The semantics is 
given in Section 2.) 

Perhaps the most novel aspect of Fran is its implicit treat- 
ment of time. This provides a great deal of expressiveness 
to the multimedia programmer, but also presents interesting 
challenges with respect to both formal semantics and imple- 
mentation. In particular, events may be specified in terms 
of boolean functions of continuous time. These functions 
may become true for arbitrarily brief periods of time, even 
instantaneously, and so it is challenging for an implemen- 
tation to detect these events. We solve this problem with 
a robust and efficient method for event detection based on 
interval analysis. (Implementation issues are discussed in 
Section 4.) 

Specifically, the nature of an event can be exploited to 
eliminate search over intervals of time in which the event 
provably does not occur, and focus intead on time inter- 
vals in which the event may occur. In some cases, such as a 
collection of bouncing balls, exact event times may be deter- 
mined analytically. In general and quite frequently, however, 
analytic techniques fail to apply. We describe intead an al- 
gorithm for event detection based on interval analysis and 
relate it to the partial information structure on the CPO of 
event times. 

2 The Formal Semantics of Fran 

The two most fundamental notions in Fran are behaviors 
and events. We treat them as a pair of mutually recursive 
polymorphic data types, and specify operations on them via 
a denotational semantics. (The "media types" we often use 
with events and behaviors will be treated formally in a later 
paper; but see also [7].) 

2.1 Semantic Domains 

The abstract domain of time is called Time. The abstract 
domains of polymorphic behaviors (a-behaviors) and poly- 
morphic events (a-events) are denoted Rehavior a and Event a , 
respectively. 
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Most of our domains (integers, booleans, etc.) are stan- 
dard, and require no explanation. The Time domain, how- 
ever, requires special treatment, since we wish values of time 
to include partial elements. In particular, we would like to 
know that a time is "at least" some value, even if we don't 
yet know exactly what the final value will be. To make this 
notion precise, we define a domain (pointed CPO) of time 
as follows: 

Denote the set of real numbers as 9?, and include in that 
set the elements oo and — oo. This set comes equipped with 
the standard arithmetic ordering <, including the fact that 
— oo < x < oo for all x £ 5R. 

Now dehne Time = 5R + 5R, where elements in the sec- 
ond "copy" of 5R are distinguished by prefixing them with 
>, as in >42, which should be read: "at least 42." Then 
define -Lfime = >( — °°)> an ^ i ^he domain (i.e. information) 
ordering on Time by: 

x U. x, W £ 5R 

>x U. y ifx<y, Vi,yeS 
>£ C >y ifx<y, W, y £ K 

It is easy to see that 1 jj rae is indeed the bottom element. 
Also note that a limit point y is just the LUB of the set of 
partial elements ( "pre-times") that approximate it: 

y=\_\{>x\x<y} 

Since the ordering on the domain Time is chain-like, and 
every such chain has a LUB (recall that 5R has a top element 
oo), the domain Time is a pointed CPO. This fact is neces- 
sary to ensure that recursive definitions are well defined. 

Elements of Time are most useful for approximating the 
time at which an event occurs. That is, an event whose time 
is approximately >t is one whose actual time of occurrence 
is greater than t. Note that the time of an event that never 
occurs is just oo, the LUB of 5R. 

Finally, we extend the definition of arithmetic < to all 
of Time by defining its behavior across the subdomains as 
follows: 

x < >y if x < y 

This can be read: "The time x is less than or equal to a time 
that is at least y, if x < y." (>x < y and >x < >y are 
undefined.) We can easily show that this extended function 
of type Time — > Time — > Bool is continuous with respect to 
C. It is used in various places in the semantics that follows. 

Semantic Functions We define an interpretation of 
a-behaviors as a function from time to a-values, producing 
the value of a behavior b at a time t. 

at : Behavior a — > Time — > a 

Next, we define an interpretation on a-events as simply non- 
strict Time x a pairs, describing the time and information 
associated with an occurrence of the event. 

occ : Event a — > Time x a 

Now that we know the semantic domains we are working 
with, we present the various behavior and event combinators 
with their formal interpretations. 



2.2 Semantics of Behaviors 

Behaviors are built up from other behaviors, static (non- 
time-varying) values, and events, via a collection of con- 
structors (combinators). 

Time. The simplest primitive behavior is time, whose 
semantics is given by: 

time : Behavior-p- me 
at[time]t = t 

Thus at [time] is just the identity function on Time. 

Lifting. We would like to have a general way of "lifting" 
functions defined on static values to analogous functions de- 
fined on behaviors. This lifting is accomplished by a (con- 
ceptually infinite) family of operators, one for each arity of 
functions. 

lift n : (a i a n j3) 

Behavior ai Behavior an — > Behaviorp 

at[/a/t„ / 6i . . . b n Jt = f (atpu]t) . . . (at[6 n ]t) 

Note that constant value lifting is just lift 0 . 

Notational aside: In practice, lifting is needed quite fre- 
quently, so it would be inconvenient to make lifting explicit 
everywhere. It is more desirable to use familiar names like 
"sin", "cos", "+", "*", and even literals like "3" and "fc/ue", 
to refer to lifted versions of their standard interpretations. 
For instance, a literal such as 42 should behave as the con- 
stant behavior "/i/t 0 42," and a summation on behaviors 
such as "&i + 62" should behave as "/i/t 2 (+) 61 62", where 
"(+)" is curried addition. In our implementation of Fran in 
Haskell, type classes help considerably here, since the Hum 
class provides a convenient implicit mechanism for lifting 
numerical values. In particular, with a suitable instance 
declaration, we achieve exactly the interpretations above, 
even for literal constants. 

Time transformation. A time transform allows the 
user to transform local time-frames. It thus supports what 
we call temporal modularity for behaviors of all types. (Sim- 
ilarly, 2D and 3D transforms support spatial modularity in 
image and geometry behaviors.) 

time'Transform : Behavior a — > Behaviorj>- me — > Behavior a 
a.t\timeTransform b tbj = at [6] o at[i&] 

Thus note that time is an identity for timeTransform: 

timeTransform b time = b 

As examples of the use of time transformation in Fran, 
the expression: 

time'Transform b (time/2) 
slows down the animation 6 by a factor of 2, whereas: 

timeTransform b (time — 2) 
delays it by 2 seconds. 



4 



Functional Reactive Animation 



Integration. Integration applies to real-valued as well 
as 2D and 3D vector-valued behaviors, or more generally, to 
vector-spaces (with limits). Borrowing from Haskell's type 
class notation to classify vector-space types: 

integral : VectorSpace a Behavior a — > Time — > Behavior a 
at[ integral b tojt = J* at [6] 

Integration allows the specification of velocity behaviors, 
and, if used twice, acceleration behaviors. For example, if 
the velocity of a moving ball is given by behavior b (perhaps 
a constant velocity, perhaps not), then its position relative 
to starting time to is given by integral b to . This provides a 
natural means to express physics-based animations, exam- 
ples of which are given in Section 3. 

Reactivity. The key interplay in Fran is that between 
behaviors and events, and is what makes behaviors reactive. 
Specifically, the behavior b untilB e exhibits 6's behavior 
until e occurs, and then switches to the behavior associated 
with e. More formally: 

untilB : Behavior a — > Event g enav i or Behavior a 
at [6 untilB e]t = if t < t e then at[6]t else at[6']t 
where (t e ,b r ) = occ[e] 

Note that the inequality used here, t < i e , is the one defined 
in Section 2.1. In the next section examples of reactivity are 
given for each of the various kinds of events. 

2.3 Semantics of Events 

Event handling. In order to give examples using spe- 
cific kinds of events, we first describe the notion of event 
handlers, which are applied to the time and data associated 
with an event using the following operator: 

(+=4>) : Event a — » ( Time — > a — > (3) — > Eventp 
occ[e +=> /] = (t e , / t e x) 
where (i e , x) = occ[e] 

For convenience, we will also make use of the following 
derived operations, which ignore the time or the data or 
both: 

(^=>) : Event a — > (a —¥ (3) — > Eventp 
(*=>) : Event a — > ( Time — > (3) — > Eventp 
(— =4>) : Eventa — > P — > Eventp 

ev g = ev +=4> Xt x. g x 

ev *=> h = ev +=4> Xt x. h t 

ev — =4> x' = ev +=4> At x. x' 

These different operator symbols are somewhat neumonic: 
(+=**) receives all of the parameters, (— =>) receives none 
of the parameters, (*=>) receives only the time, and (^=>) 
receives only the data. 

Constant events. The simplest kind of event is one 
specified directly by its time and value. 

constEv : Time — > a — > Event a 
occ^constEv t e xj = (t e , x) 

Thus, for example, the behavior: 

6i untilB (constEv 10 x)— =4> 62 

exhibits behavior 61 until time 10, at which point it begins 
exhibiting behavior 62 (x is ignored in this example, but of 
course needn't be). 



External events. For this paper we only consider one 
kind of external event — mouse button presses — which can 
be from either the left or right button. The value associated 
with a button press event is the corresponding button release 
event, which in turn yields a unit value (() is the unit type): 

Ibp, rbp : Time — > Event ]<; ven i 

The meaning of an event Ibp to, for example, is the pair 
(t e ,e), such that t e is the time of the first left button press 
after to, and e is the event corresponding to the first left 
button release after t e . Thus the behavior: 

61 untilB (Ibp to) Xe. 

62 untilB e— =3- 
63 

exhibits behavior 61 until the left button is pressed, at which 
point it becomes 62 until the left button is released, at which 
point it becomes 63 . 

Predicates. It is natural to want to specify certain events 
as the first time that a boolean behavior becomes true after 
a given time. 

predicate : Behaviorg gg i — > Time — > EventQ 
occfpredicate b to] = (inf {t > to \ at [&]£}, () ) 

That is, the time of a predicate event is the infimum of the 
set of times greater than to at which the behavior is true. 
Note that this time could be equal to to . 
The behavior: 

61 untilB (predicate (sin time = 0.5) to)— =4> 62 

thus exhibits 61 until the first time t after to that sin t is 
0.5, after which it exhibits 62. 

If the boolean behavior argument to predicate were an ar- 
bitrarily complex computable function, then predicate would 
not be computable. To cope with this problem, we re- 
strict behaviors somewhat, to make predicate not only com- 
putable, but also efficient. We will return to this issue in 
Section 4.2. 

Choice. We can choose the earlier of two events with the 
.|. operator: 

(.|.) : Eventa — > Event a — > Event a 
occ[e .|. e'] = (t s ,x), if t e < t' e 
= (t' e ,x'), otherwise 
where (t e , x) = occ[e] 
(t^, x') = occ[e'] 

For example, this behavior: 

61 untilB (Ibp to .|. predicate (time > 5) to)— ^ 62 

waits for either a left button press or a timeout of 5 seconds 
before switching from behavior 61 to behavior 62- As an 
alternative, the following example switches to a different 
behavior, 63, upon timeout. 

61 untilB (Ibp to — =4> 62 -|- predicate (time > 5) to — =4> 63) 
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Snapshot. At the moment an event occurs it is often 
convenient to take a "snapshot" of a behavior's value at 
that point in time. 

snapshot: Event a — > Behaviorp — > Event ax p 
occ[e snapshot bj = (t e , (x, at[6]t e )) 
where (t s ,x) = occ[e] 

For example, the behavior: 

61 untilB (Ibp to snapshot (sin time)) A(e, y). 62 

grabs the sine of the time at which the left button is pressed, 
binds it to y, and continues with behavior 62 which pre- 
sumably depends on y. Although this example could also 
be achieved by grabbing the time of the left button press 
event and computing its sine, in general the behavior be- 
ing snapshot can be arbitrarily complex, and may in fact be 
dependent on external events. 

Event sequencing. It is sometimes useful to use one 
event to generate another. The event joinEv e is the event 
that occurs when e' occurs, where e' is the value part of e. 

joinEv: Event £ ven t — > Event a 
occ\joinEv e] = acc\snd (occ[e])J 

(This function is so named because it is the "join" operator 
for the Event monad [22].) 
For example, the event 

joinEv (Ibp to*=> predicate (b = 0)) 

occurs the first time that the behavior b has the value zero 
after the hrst left button press after time to . 

3 Some Larger Examples 

The previous section presented the primitive combinators 
for behaviors and events, along with their formal semantics. 
The following examples illustrate the use of some of these 
combinators. The examples are given as Haskell code, whose 
correspondence to the formal semantics should be obvious. 
(All values in these examples are behaviors, though we do 
not explicitly say so.) 

To begin, let's define a couple of simple utility behaviors. 
The first varies smoothly and cyclically between -1 and +1. 

wiggle = sin (pi * time) 

Using wiggle we can define a function that smoothly varies 
between its two argument values. 

wiggleRange lo hi = 

lo + (hi-lo) * (wiggle+l)/2 

Now let's create a very simple animation: a red, pulsat- 
ing ball. 

pBall = withColor red 

(bigger (wiggleRange 0.5 1) circle) 

The function bigger scales its second argument by the amount 
specified by its first argument; since the first argument is a 
behavior, the result is also a behavior, in this case a ball 
whose size varies from full size to half its full size. 

A key attribute of Fran is that behaviors are composable. 
For example, pBall can be further manipulated, as in: 



rBall = move (vectorPolar 2.0 time) 
(bigger 0.1 pBall) 

which yields a ball moving in a circular motion with radius 
2.0 at a rate proportional to time. The ball itself is the same 
as pBall (red and pulsating), but 1/10 the original size. 

Certain external phenomena can be treated as behaviors, 
too. For example, the position of the mouse can naturally 
be thought of as a vector behavior. Thus to cause an image 
to track exactly the position of a mouse, all we need to do 
is: 

followMouse im tO = move (mouse tO) im 

(The function move shifts an image by an offset vector.) 

Another natural way to define an animation is in terms 
of rates. For example, we can expand on the mouse-follower 
idea by having the image follow the mouse at a rate that is 
dependent on how far the image is from the current mouse 
position. 

f ollowMouseRate im tO = move offset im 
where offset = integral rate tO 
rate = mouse tO .-. pos 
pos = origin2 . +" offset 

Note the mutually recursive specification of offset, rate, 
and pos: The offset starts out as the zero vector, and grows 
at a rate called rate. The rate is defined to be the dif- 
ference between the mouse's location (mouse is a primitive 
behavior that represents mouse position) and our anima- 
tion's position pos. pos, in turn, is defined in terms of the 
offset relative to the origin. As a result, the given image al- 
ways pursues the mouse, but moves faster when the distance 
is greater. (The operation . +" adds a point and a vector, 
yielding a point, and .-. subtracts two points, yielding a 
vector.) 

As a variation, we can virtually attach the image to the 
mouse cursor using a spring. The definition is very similar, 
with position defined by a starting point and a growing off- 
set. This time, however, the rate is itself changing at a rate 
we call accel. This acceleration is defined in part by the 
difference between the mouse position and the image's posi- 
tion, but we also add some drag that tends to slow down the 
image by adding an acceleration in the direction opposite to 
its movement. (Increasing or decreasing the "drag factor" 
of 0.5 below creates more or less drag.) 

f ollowMouseSpring im tO = move offset im 
where offset = integral rate tO 
rate = integral accel tO 
accel = (mouse tO .-. pos) - 0.5 *" rate 
pos = origin2 . +" offset 

(The operator *" multiplies a real number by a vector, yield- 
ing a vector.) 

As an example of event handling, the following behavior 
describes a color that changes between red and blue each 
time the left button is pressed. We accomplish this change 
with the help of a function cycle that takes two colors, cl 
and c2, and gives an animated color that starts out as cl. 
When the button is pressed, it swaps cl and c2 and repeats 
(using recursion). 

animl2 tO = withColor (cycle red blue tO) circle 
where cycle cl c2 tO = 

cl 'untilB' Ibp tO *=> cycle c2 cl 
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bounce minVal maxVal yO vO g tO = path 
where path = start tO (yO,vO) 

start tO (yO,vO) = y 'untilB' doBounce +=> start 

where y = liftO yO + integral v tO 
v = liftO vO + integral g tO 
reciprocity =0.8 

doBounce : : Event (RealVal, RealVal) — returns new y and v 

doBounce = (collide 'snapshot' pairB y v) ==> snd ==> \ (yHit,vHit) -> 

(yHit , - reciprocity * vHit) 
collide = predicate (y <=* liftO minVal &&* v<=*0 I I* 
y >=* liftO maxVal &&* v>=*0) tO 



Figure 1: One-Dimensional Bounce 



Note that the Time argument in the recursive call to cycle 
is supplied automatically by *=>. 

The next example is a number- valued behavior that starts 
out as zero, and becomes -1 while the left button is pressed 
or 1 while the right button is pressed. 

bSign tO = 

0 'untilB' lbp tO ==> nonZero (-1) . |. 
rbp tO ==> nonZero 1 
where nonZero r stop = 

r 'untilB' stop *=> bSign 

We can use the function bSign above to control the rate 
of growth of an image. Pressing the left (or right) button 
causes the image to shrink (or grow) until released. Put 
another way, the rate of growth is 0, -1, or 1, according to 
bSign. 

grow im tO = bigger size im 
where size = 1 + integral rate tO 
rate = bSign tO 

A very simple modification to the grow function above 
causes the image to grow or shrink at the rate of its own 
size (i.e. exponentially). 

grow' im tO = bigger size im 
where size = 1 + integral rate tO 
rate = bSign tO * size 

Here's an example that demonstrates that even colors 
can be animated. Using the function rgb, a color behavior 
is created by fixing the blue component, but allowing the 
red and green components to vary with time. 

withColor (rgb (abs (cos time)) 

(abs (sin (2*time))) 
0.5) 
circle 

As a final example, let's develop a modular program to 
describe "bouncing balls." First note that the physical equa- 
tions describing the position y and velocity v at time t of an 
object being accelerated by gravity g are: 

y = yo + J* v dt 

v = v 0 + f g dt 

J to 



where yo and vo are the initial position and velocity, respec- 
tively of the object at time to. In Fran these equations are 
simply: 

y = liftO yO + integral v tO 
v = liftO vO + integral g tO 

Next we define a function bounce that, in addition to 
computing the position of an object based on the above 
equations, also determines when the ball has hit either the 
floor or the ceiling, and if so reverses the direction of the 
ball while reducing its velocity by a certain reciprocity, to 
account for loss of energy during the collision. The code for 
bounce is shown in Figure 1. Note that collision is defined 
as the moment when either the position has exceeded the 
minVal and the velocity is negative, or the position has ex- 
ceeded the maxVal and the velocity is positive. When such 
a collision is detected, the current position and velocity are 
snapshot, and the cycle repeats with the velocity negated 
and scaled by the reciprocity factor. (The various opera- 
tors with * after them are lifted versions of the underlying 
operators.) 

Now that bounce is defined, we can also use it to de- 
scribe horizontal movement, using 0 for acceleration. Thus 
to simulate a bouncing ball in a box, we can simply write: 

moveXY x y 

(withColor green circle) 
where 

x = bounce xMin xMax xO vxO 0 tO 
y = bounce yMin yMax yO vyO g tO 

where xMin, xMax, yMin, and yMax are the dimensions of the 
box. 

4 Implementation 

The formal semantics given in Section 2 could almost serve 
as an implementation, but not quite. In this section, we de- 
scribe the non-obvious implementation techniques used in 
Fran. One relatively minor item is integration. While sym- 
bolic integration could certainly be used for simple behav- 
iors, we have instead adapted standard textbook numerical 
techniques. (We chiefly use fourth order Runge Kutta [17].) 
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4.1 Representing Behaviors 

An early implementation of Fran represented behaviors as 
implied in the formal semantics: 

data Behavior a = Behavior (Time -> a) 

This representation, however, leads to a serious inefficiency. 
To see why, consider a simple sequentially recursive reactive 
behavior like the following. 

b = toggle True 0 
where toggle val tO = 

liftO val 'untilB' lbp tO *=> 
toggle (not val) 

This behavior toggles between true and false whenever the 
left button is pressed. Suppose b is sampled at a time t\ after 
the first button press, and we then need to sample b at a 
time ti > t\ . Then b needs to notice that £2 is after the first 
button press, and then see whether it is also beyond the 
second button press. After n such events, sampling must 
verify that their given times are indeed past n events, so 
the running time and the (lazily expanded) representation 
would be 0{n). One could try to eliminate this "space- 
time leak" by switching to a stateful implementation, but 
doing so would interfere with a behavior's ability to support 
multiple simultaneously time-transformed versions of itself. 

We solve this problem by having behavior sampling gen- 
erate not only a value, but also a new, possibly simpler, 
behavior. 

data Behavior a = 

Behavior (Time -> (a, Behavior a)) 

(In fact, we use a slightly more complex representation, as 
explained in Section 4.2 below.) Once an event is detected 
to be (t e , 6'), the new behavior is sampled and the resulting 
value and possibly an even further simplified version are re- 
turned. In most cases (ones not involving time transform), 
the original untilB behavior is then no longer accessible, and 
so gets garbage collected. Note that this optimization im- 
plies some loss of generality: sampling must be done with 
monotonically non-decreasing times. 

These same efficiency issues apply as well to integration, 
eliminating the need to re-start integration for each sam- 
pling. (In fact, our formulation of numerical integration is 
as sequentially recursive reactive behaviors.) 

4.2 Implementing Events 

There are really two key challenges with event detection: 
(a) how to avoid trying too soon to catch events, and (b) 
how to catch events efficiently and robustly when we need 
to. We use a form of laziness for the former challenge, and 
a technique called interval analysis for the latter. 

Representing events lazily. Recall the semantics 
of reactivity: 

untilB: Behavior a — > Event g enav i or Behavior a 
at [6 untilB ejt = if t < t s then atpjft else at[6']t 
where (t s ,b') = occ[e] 

Note that values of an untilB-hased behavior at t < t e 
do not depend on the precise value of t e , just the partial 
information about t e that it is at least t. This observation 



is crucial, because it may be quite expensive or, in the case of 
user input, even impossible to know the value of t e before the 
time t e arrives. Instead, we represent the time t e by a chain 
of lower-bound time values increasing monotonically with 
respect to the information ordering defined in Section 2.1. 
Because these chains are evaluated lazily, detection is done 
progressively on demand. 

Detecting predicate events. The second imple- 
mentation challenge raised by events is how to determine 
when predicate events occur. For instance, consider the 
event that occurs when te 4t = 10: 

predicate (time * exp (4 * time) ==* 10) 0 

Any technique based solely on sampling of behaviors must 
fail to detect events like this whose boolean behaviors are 
true only instantaneously. An alternative technique is sym- 
bolic equation solving. Unfortunately, except for very simple 
examples, equations cannot be solved symbolically. 

The technique we use to detect predicate events is in- 
terval analysis (IA) [20]. It uses more information from a 
behavior than can be extracted purely through sampling, 
but it does not require symbolic equation solving. Instead, 
every behavior is able not only to tell how a sample time 
maps to a sample value, but also to produce a conservative 
interval bound on the values taken on by a behavior over 
a given interval 7. More precisely, the operation during, 
mapping time intervals to a intervals, has the property that 
at[6]t 6 duringp)]/ for any a- valued behavior b, time in- 
terval 7, and time t £ 7. 

An interval is represented simply as a pair of values: 

data Ivl a = a 'Upto' a 

For instance, "3 'Upto' 10" represents the interval [3,10], 
i.e., the set of x such that 3 < x < 10. The implementa- 
tion of a behavior then contains both the time-sampling and 
interval-sampling functions: 

data Behavior a = 

Behavior (Time -> (a, Behavior a)) 

(Ivl Time -> (Ivl a, Behavior a)) 

As an example, the behavior time maps times and time 
intervals to themselves, and returns an unchanged behavior. 

time : : Behavior Time 
time = Behavior (\ t -> (t , time)) 
(\ iv -> (iv, time)) 

"Lifting" of functions to the level of behaviors works sim- 
ilarly to the description in Section 2, but additionally maps 
domain intervals to range intervals, and re-applies the lifted 
functions to possibly altered behavior arguments. For in- 
stance, lift 2 is implemented as follows. 

Iift2 f fi bl b2 = Behavior sample isample 
where sample t = (f xl x2, lift2 f fi bl' b2 ' ) 
where (xl , bl') = bl 'at' t 
(x2 , b2 ' ) = b2 ' at ' t 
isample iv = (fi xil xi2, lift2 f fi bl ' b2 ' ) 
where (xil, bl') = bl 'during' iv 
(xi2, b2') = b2 'during' iv 

The restriction on behaviors referred to in Section 2.3 
that makes event detection possible, is that behaviors are 
composed of functions f for which a corresponding fi is 
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known in the lift n functions. (These f i are called "inclusion 
functions.") 

Defining functions' behaviors over intervals is well-under- 
stood [20], and we omit the details here, other than to point 
out that Haskell's type classes once again provide a conve- 
nient notation for interval versions of the standard arith- 
metic operators. For example, evaluating 

(2 'Upto' 4) + (10 'Upto' 30) 

yields the interval [12,34]- Also, a useful I A technique is to 
exploit intervals of monotonicity. For instance, the exp func- 
tion is monotonically increasing, while sin and cos functions 
change between monotonically increasing and monotonically 
decreasing on intervals of width 7r. 

We can also apply IA to boolean behaviors, if we consider 
booleans to be ordered with False < True. There are three 
nonempty boolean intervals, corresponding to the behavior 
being true never, sometimes, or always. For example, the 
interval form of equality checks whether its two interval ar- 
guments overlap. If not, the answer is uniformly false. If 
both intervals are the same singleton interval, then the an- 
swer is uniformly true. Otherwise, IA only knows that the 
answer may be true or false throughout the interval. Specif- 
ically: 

(lol 'Upto' hil) ==# (lo2 'Upto' hi2) 
I hil < lo2 || hi2 < lol 

False 'Upto' False 
I lol==hil && lo2==hi2 && lol==lo2 = 

True 'Upto' True 
I otherwise = 

False 'Upto' True 

Similarly, it is straightforward to define interval versions of 
the inequality operators and logical operators (conjunction, 
disjunction, and negation). 

With this background, detection of predicate events through 
IA is straightforward. Given a start time t\ , choose a time 
t-2 > t\ , and evaluate the boolean behavior over [t\ , £2], yield- 
ing one of the three boolean intervals listed above. If the 
result is uniformly false, then £2 is guaranteed to be a lower 
bound for the event time. If uniformly true, then the event 
time is t\ (which is the inhmum of times after t\). Oth- 
erwise, the interval is split in half, and the two halves are 
considered, starting with the earlier half (because we are 
looking for the first time the boolean behavior is true). At 
some point in this recursive search, the interval being di- 
vided becomes smaller than the desired degree of temporal 
accuracy, at which point event detection claims a success. 

This event detection algorithm is captured in the def- 
inition of predicate given in Appendix A. This function 
uses the above divide-and-conquer strategy in narrowing 
down the interval, but also, a rfoufc/e-and-conquer strategy 
in searching the right-unbounded time interval. The idea 
that if the event was not found in the next w seconds, then 
perhaps we should look a bit further into the future — 2w 
seconds — the next time around. 

It is also possible to apply I A to positional user input. 
The idea is to place bounds on the rate or acceleration of 
the positional input, and then make a worst-case analysis 
based on these bounds. We have not yet implemented this 
idea. 



5 Related Work 

Henderson's functional geometry [12] was one of the first 
purely declarative approaches to graphics, although it does 
not deal with animation or reactivity. Several other re- 
searchers have also found declarative languages well-suited 
for modeling pictures. Examples include [15, 23, 3, 10]. 

Arya used a lazy functional language to model 2D an- 
imation as lazy lists of pictures [1, 2], constructed using 
list combinators. While this work was quite elegant, the 
use of lists implies a discrete model of time, which is some- 
what unnatural. Problems with a discrete model include the 
fact that time-scaling becomes difficult, requiring throwing 
away frames or interpolation between frames, and rendering 
an animation requires that the frame rate match the dis- 
crete representation; if the frames cannot be generated fast 
enough, the perceived animation will slow down. Our con- 
tinuous model avoids these problems, and has the pleasant 
property that animations run at precisely the same speed, 
regardless of how fast the underlying hardware is (slower 
hardware will generate less smooth animations, but they 
will still run at the same rate). 

The TBAG system modeled 3D animations as functions 
over continuous time, using a "behavior" type family [8, 19]. 
These behaviors are built up via combinators that are auto- 
matically invoked during solution of high level constraints. 
Because it used continuous time, TBAG was able to support 
derivatives and integrals. It also used the idea of elevating 
functions on static values into functions on behaviors, which 
we adopted. Unlike our approach, however, reactivity was 
handled imperatively, through constraint assertion and re- 
traction, performed by an application program. 

CML (Concurrent ML) formalized synchronous opera- 
tions as hrst-class, purely functional, values called "events" 
[18]. Our event combinators ". I ." and "==>" correspond 
to CML's choose and wrap functions. There are substantial 
differences, however, between the meaning given to "events" 
in these two approaches. In CML, events are ultimately used 
to perform an action, such as reading input from or writing 
output to a hie or another process. In contrast, our events 
are used purely for the values they generate. These values 
often turn out to be behaviors, although they can also be 
new events, tuples, functions, etc. 

Concurrent Haskell [14] extends the pure lazy functional 
programming language Haskell with a small set of primitives 
for explicit concurrency, designed around Haskell's monadic 
support for I/O. While this system is purely functional in 
the technical sense, its semantics has a strongly imperative 
feel. That is, expressions are evaluated without side-effects 
to yield concurrent, imperative computations, which are ex- 
ecuted to perform the implied side-effects. In contrast, mod- 
eling entire behaviors as implicitly concurrent functions of 
continuous time yields what we consider a more declarative 
feel. 

Haskore [13] is a purely functional approach to construct- 
ing, analyzing, and performing computer music, which has 
much in common with Henderson's functional geometry, even 
though it is for a completely different medium. The Haskore 
work also points out useful algebraic properties that such 
declarative systems possess. Other computer music lan- 
guages worth mentioning include Canon [5], Fugue [6], and a 
language being developed at GRAME [16] , only the latter of 
which is purely declarative. Fugue also highlights the util- 
ity of lazy evaluation in certain contexts, but extra effort is 
needed to make this work in its Lisp-based context, whereas 
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in a non-strict language such as Haskell it essentially comes 
"for free." 

DirectX Animation is a library developed at Microsoft to 
support interactive animation. Fran and DirectX Animation 
both grew out of the ideas in an earlier design called Ac- 
tive VRML [7] . DirectX Animation is used from more main- 
stream imperative languages, and so mixes the functional 
and imperative approaches. 

There are also several languages designed around a syn- 
chronous data-flow notion of computation. The general- 
purpose functional language Lucid [21] is an example of this 
style of language, but more importantly are the languages 
Signal [11] and Lustre [4], which were specifically designed 
for control of real-time systems. 

In Signal, the most fundamental idea is that of a signal, a 
time-ordered sequence of values. Unlike Fran, however, time 
is not a value, but rather is implicit in the ordering of values 
in a signal. By its very nature time is thus discrete rather 
than continuous, with emphasis on the relative ordering of 
values in a data-flow-like framework. The designers of Signal 
have also developed a clock calculus with which one can 
reason about Signal programs. Lustre is a language similar 
to Signal, rooted again in the notion of a sequence, and 
owing much of its nature to Lucid. 
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6 Conclusions 

Writing rich, reactive animations is a potentially tedious and 
error-prone task using conventional programming method- 
ologies, primarily because of the attention needed for issues 
of presentation. We have described a system called Fran that 
remedies this problem by concentrating on issues of model- 
ing, leaving presentation details to the underlying implemen- 
tation. We have given a formal semantics and described an 
implementation in Haskell, which runs acceptably fast using 
the Hugs interpreter. Future work lies in improving perfor- 
mance through the use of standard compilation methods as 
well as domain-specihc optimization techniques; extending 
the ideas to 3D graphics and sound; and investigating other 
applications of this modeling approach to software develop- 
ment. 

Our implementation of Fran currently runs under the 
Windows '95/NT version of Hugs, a Haskell implementation 
being developed collaboratively by Yale, Nottingham, and 
Glasgow Universities. It is convenient for developing anima- 
tion programs, because of quick turn-around from modifica- 
tion to execution, and it runs with acceptable performance, 
for a byte-code interpreter. We expect marked performance 
improvement once Fran is running under GHC (the Glasgow 
Haskell Compiler). Even better, when these two Haskell im- 
plementations are integrated, Fran programs will be conve- 
nient to develop and run fast. The Hugs implementation, 
which includes the entire Fran system, may be retrieved from 
http://www.haskell.org/hugs. Although this paper will 
give the reader an understanding of the technical ideas un- 
derpinning Fran, its power as an animation engine (and how 
much fun it is to play with!) can only be appreciated by us- 
ing it. 
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Appendix A: Haskell Code for Predicate Event Detection 



type BoolB = Behavior Bool 
type Timel = Ivl Time 

predicate : : BoolB -> Time -> Event () 

predicate cond tO = predAfter cond tO 1 
where 

predAfter cond tO width = 

predln cond (tO 'Upto' tO+width) ( \ cond' -> 
predAfter cond' (tO+width) (2*width) ) 

predln :: BoolB -> Timel -> (BoolB -> Event ()) -> Event () 
predln cond iv tryWext = 
case vail of 

False 'Upto' False -> — no occurrence 

-- Note lower bound and try the next condition. 

timelsAtLeast hi (tryNext cond') 
False 'Upto' True -> — found at least one 

if hi-mid <= eventEpsilon 

then constEv mid () 

else predln cond (lo 'Upto' mid) ( \ midCond -> 
predln midCond (mid 'Upto' hi) tryNext ) 
True 'Upto' True -> constEv lo () — found exactly one 

where 

lo 'Upto' hi = iv 

mid = (hi+lo)/2 

ivLef tTrimmed = lo + lef tSkipWidth 'Upto' hi 
(valI,cond') = cond 'during' ivLef tTrimmed 

— Interval size limit for temporal subdivision 
eventEpsilon = 0.001 :: Time 

— Simulate lef t-open-ness via a small increment 
leftSkipWidth = 0.0001 :: Time 



